home *** CD-ROM | disk | FTP | other *** search
/ Deutsche Edition 1 / Deutsche Edition 1.iso / amok / 071-080 / amok73 / ums / doc / ums-mf.doc < prev    next >
Text File  |  1993-11-04  |  9KB  |  285 lines
  1.  
  2.   UMS Message Format $VER: 9.2 (17.7.92)
  3.  
  4.   This text is (C) 1992 by Martin Horneffer.
  5.  
  6.   It  may  freely be copied and distributed, as long the the
  7. text is unchanged and this copyright notice is left intact.
  8.  
  9.  
  10.  
  11.  
  12. The Universal Message System universal message format.
  13.  
  14.  
  15.  
  16. A  message  in  the  UMS message base is always defined by a
  17. list  of tags.  This allows the format to be easily extended
  18. as new tag may always be defined later on.
  19.  
  20. In one UMS message, each tag may occur only once.
  21.  
  22. Some  tags  are somehow implementation-dependend - these are
  23. documented  somewhere  else.
  24.  
  25. This  document describes the format of the currently defined
  26. TEXT-tags.   Currently  these  tags  include all information
  27. that   is   site-independend  and  needed  when  transfering
  28. messages   between   different   systems.
  29.  
  30. Most of these tags are network-independent.  Drivers for all
  31. networks can and must understand them.
  32.  
  33.  
  34. A text-tag specifies a null-terminated string of any length.
  35. All  ASCII-characters are allowed.  Unless something else is
  36. documented  for a specific tag, the ISO 8859-Latin 1 charset
  37. is used for 8-bit characters.
  38.  
  39. Some of the text-tags are required for every message, others
  40. are optional.
  41.  
  42.  
  43.  
  44. 0) "MsgText"
  45.  
  46. This  contains  the main 'text' of a message.  Every message
  47. must  have  this  tag  as it is usually the main information
  48. transported by a message.
  49.  
  50. Any  information  that  does not belong to teh original text
  51. must  not  be  put  here.   Even  when a gateway between two
  52. different  networks  puts  information  in  the text, an UMS
  53. importer should - if possible - extract this information and
  54. use or store it somewhere else.
  55.  
  56. The  text  may  be  of  any size.  Since some networks limit
  57. messages  to a certain size, drivers for these networks must
  58. be able to cope with this situation.
  59.  
  60. Lines  are  delimited by the standard line delimiter (LF for
  61. the  Amiga;  may be different fpr other systems).  Lines may
  62. be  of  any length, so it's up to the newsreader or exporter
  63. to wrap lines if needed.
  64.  
  65.  
  66. 1) 'FromName'
  67.  
  68. This  is  the  name  of the message's author.  It's ONLY the
  69. name (the 'realname', if possible), NOT the address.
  70.  
  71. If  there  is  no  realname,  the  username  must be used or
  72. extracted from the author's address.
  73.  
  74. Every message must have this tag.
  75.  
  76.  
  77. 2) 'FromPath'
  78.  
  79. This   is   the  author's  net-address.   The  name  needn't
  80. redundantly  be  repeated  in this field, if it's already in
  81. 'FromName'.
  82.  
  83. This tag must be empty (i.e.  the tag may not occur), if the
  84. author  is located on the local system.  In every other case
  85. this tag is needed.
  86.  
  87. Whenever  possible,  the  address  should be the user's real
  88. address  and not an encapsulated address or the address of a
  89. gateway.   Thus it may be necessary for importers to convert
  90. received   addresses   to  another  network's  format.   The
  91. corresponding  exporters,  of  course,  have  to  be able to
  92. re-convert   these   address.    This  makes  used  gateways
  93. transparent  to  the  user  -  one  of  UMS'  most important
  94. features.   It  saves the user from having to know and worry
  95. about all the gateways' formats himself.
  96.  
  97.  
  98. Since there are different networks with different formats of
  99. addresses,  it's  neccessary  to distinguish these different
  100. formats.   This  is  done  by  looking  at the "tail" of the
  101. address.  The following formats are currently known:
  102.  
  103.   Identifier                          : network/format
  104.   ----------------------------------------------------
  105.   "@Fidonet"                          : FidoNet
  106.   ".maus"                             : MausNet
  107.   ".zer"                              : Z-Net
  108.   ".org", ".sub", ".edu", ".UUCP",
  109.   ".de", .. [any valid usenet domain] : RFC
  110.  
  111. E.g.,  "2:242/7.9@Fidonet"  is an address in Fidonet format.
  112. "ac2.maus"  is  MausNet format, "maho@dfv.rwth-aachen.de" is
  113. RFC.
  114.  
  115. Network-identifiers are NOT case-sensitiv.  Nevertheless you
  116. always  should  preserve case, as it might be needed by some
  117. networks.
  118.  
  119. Some examples for splitting addresses in 'Name' and 'Path':
  120.  
  121. RFC:
  122.  
  123. "Martin Horneffer <maho@balrog.dfv.rwth-aachen.de>"
  124. -> name: "Martin Horneffer"
  125.    path: "maho@balrog.dfv.rwth-aachen.de"
  126.  
  127. "horneff@pool.informatik.rwth-aachen.de (Martin Horneffer)"
  128. -> name: "Martin Horneffer"
  129.    path: "horneff@pool.informatik.rwth-aachen.de"
  130.  
  131. "horneff@pool.informatik.rwth-aachen.de"
  132. -> name: "horneff"
  133.    path: "horneff@pool.informatik.rwth-aachen.de"
  134.  
  135. FidoNet:
  136.  
  137. "Martin Horneffer at 2:242/7.9"
  138. -> name: "Martin Horneffer"
  139.    path: "2:242/7.9@Fidonet"
  140.  
  141. "Joerg Gutzke at 2:242/7"
  142. -> name: "Joerg Gutzke"
  143.    path: "2:242/7@Fidonet"
  144.  
  145.  
  146. 3) 'ToName'
  147.  
  148. Name of the person the message is addressed to.
  149.  
  150. Must  be specified in all private messages ("e-mail") and is
  151. optional in public messages ("news").
  152.  
  153.  
  154. 4) 'ToAddress'
  155.  
  156. Network-address of the addressed person.
  157.  
  158. Needed  in  private  messages  if  the  message  has not yet
  159. reached  its destination.  Must not be used when the mail is
  160. addressed to a user on the local system.
  161.  
  162. 'ToName'  and  'ToPath'  have  exactly  the  same  format as
  163. 'FromName' and 'FromPath'.
  164.  
  165. It  must  always be possible to reply to a private or public
  166. message  by  using  it's  FromName  and  FromPath as the new
  167. ToName and ToPath.
  168.  
  169.  
  170. 5) 'MsgID'
  171.  
  172. A  unique  message ID in RFC-format.  This is valid also for
  173. non-RFC networks like FidoNet or Z-Net!
  174.  
  175. Every  message must have such an ID.  If there's no ID for a
  176. message,  the  message-base-processor  will create a new one
  177. for this message.  Never create message IDs on your own!
  178.  
  179.  
  180. 6) 'CreationDate'
  181.  
  182. (Optional) date of creation (i.e.  when the message has been
  183. written by the user).  May be in any format that is readable
  184. by humans.  AmigaDOS format (dd-mmm-yy hh:mm:ss) preferred.
  185.  
  186.  
  187. 7) 'ReceiveDate'
  188.  
  189. Not used any more.  Avoid this.  As a replacement there is a
  190. tag for a site-specific binary date.
  191.  
  192.  
  193. 8) 'ReferID'
  194.  
  195. (Optional)  message  ID  of  the most recent message that is
  196. referred to by the current message.  Same format as 'MsgID'.
  197.  
  198.  
  199. 9) 'Group'
  200.  
  201. Name of the message's newsgroup.
  202.  
  203. Must  be  used  for  public  messages;  may  not be used for
  204. private  mail.   This tag is the only one that distinguishes
  205. private from public messages.
  206.  
  207. To avoid possible conflicts, the name of the network must be
  208. prepended  for  non-usenet  groupnames.   Usenet groupnames,
  209. which already are hierarchically ordered, stay as they are.
  210. E.g.  "fidonet.AMIGA", "maus.ac.amiga",
  211. "comp.sys.amiga.misc".
  212.  
  213.  
  214. 10) 'Subject'
  215.  
  216. The (short) subject of the message.  Required.
  217.  
  218.  
  219. 11) 'Attributes'
  220.  
  221. (Optional)  list  of  keywords controlling the processing of
  222. the  message  and/or  telling  how  to  interpret  it.   The
  223. keywords are separated by blanks (" ").
  224.  
  225. Some known keywords for 'Attributes':
  226.  
  227.    key               meaning
  228.   -----------------------------------------
  229.   "file-attach"      the message comes with an attached
  230.                      (binary) file that should be routed
  231.                      with the message. The 'Subject'
  232.                      contains the name of the file on the
  233.                      local system.
  234.   "receipt"          the message has automatically been
  235.                      created  and  should not be replied to.
  236.                      (e.g. a "receipt" or a "bounce-mail").
  237.   "receipt-request"  author wishes to get a receipt.
  238.   "crash"            FidoNet-crashmail
  239.   "BIM"              the author illegally used IBM-PC
  240.                      special chars and needs to be flamed. ;-)
  241.  
  242.  
  243. 12) 'Comments'
  244.  
  245. (Optional)   all  "header-"information,  that  belong  to  a
  246. message  and  must  be  preserved,  but don't fit to another
  247. text-tag.  E.g.  all unknown RFC-header lines go here.
  248.  
  249.  
  250. 13) 'Organization'
  251.  
  252. (Optional) sender's organization or "Origin".
  253.  
  254.  
  255. 14) 'Distribution'
  256.  
  257. (Optional)  where/what  the  message  should  be distributed
  258. to/by.  Much like RFC-"Distribution:".
  259.  
  260.  
  261. 16) 'FidoID'
  262.  
  263. This  is  specific  to  FidoNet and should be ignored by all
  264. programs  not  specifically dealing with FidoNet.  It's used
  265. to  keep  the  internal  "^aMSGID" used within FidoNet if it
  266. cannot  be  converted  to  'MsgID'.   This  only  applies to
  267. messages  that  came from other networks and went to FidoNet
  268. through some gateway.
  269.  
  270. 17) 'MausID'
  271.  
  272. This  is  specific  to  MausNet and should be ignored by all
  273. programs  not  specifically dealing with MausNet.  It's used
  274. to   store   the   internal   MausNet-ID.   It  will  become
  275. superfluous  when  MausNet software learns to deal with real
  276. Message-IDs.
  277.  
  278.  
  279. 32) 'FidoText'
  280.  
  281. This  is  specific  to  FidoNet and should be ignored by all
  282. programs  not  specifically dealing with FidoNet.  It's used
  283. by  FidoNet  drivers  to  avoid  loss  of information due to
  284. conversions of eol-delimiters or charsets.
  285.